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programs to machines A Java "Just In Time" runs as part of 
an application, and as such, it must be fast and efiScient in its 
use of memory. To achieve good performance and further 
optimize code generation, the present invention introduces a 
^ethodfor optimizing-Javaperformance usingprecompiled; 
codeTllieltiethod of the present invention-first'monitors the 
performance of program code during program execution. 
Then a list of program functions for possible native code 
compilation is created. Tht list may be created based upon 
fstatic~and"dynamic"analysis~of the computer program. A 
iplurahljPof-^rogram'fiinciionsi from said list of program 
functions~is~selected"for"0ptin3ization and native compila- 
tion. The selected program functions are precompiled into 
native program functions. The present invention also allows 
the precompiled native code reverted so that a user could 
explore the performance tuning until satisfactory, 
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METHOD FOR OPTIMIZING JAVA 
PERFORMANCE USING PRECOMPILED 
CODE 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

This invention relates to the field of computer software 
optimization. More particularly, the present invention relates 
to a method for optimizing Java performance using precom- 
piled code. 

2. History of the Prior Art 

Computer programs are generally created as source code. 
The source code is later compiled into object code for 
program execution. Hence, most programs exist as compiled 
object code in computer systems. However, the compiled 
code is usually designed/compiled to operate on only one 
particular operating system or on only one particular com- 
puter architecture. The binary file for an application that runs 
on one platform cannot nm on another platform because the 
binary file is machine-specific. In order to use a certain 
program on several different types of computer systems, the 
original source code must be separately compiled into object 
code for each different operating system and each different 
processor architecture. 

The popularization of the World Wide Web has exacer- 
bated a problem for software developers trying to create 
software for networked consumer devices. While millions of 
people around the globe are surfing the Internet and brows- 
ing web pages with their computers, not all of those com- 
puters are the same. One person may be using a Macintosh, 
another a PC, and yet another user with a UNIX machine. 
Hence software developers may find it desirable to design 
computer programs that could support multiple host archi- 
tectures and could allow secure delivery of its software 
components. 

The Java programming language and environment is 
designed to solve a number of problems in modern pro- 
gramming practice. Java is designed to meet the challenges 
of application development in the context of heterogeneous, 
network-wide distributed environments. Paramount among 
these challenges is secure delivery of applications that 
consume the minimum of system resources, can run on any 
hardware and software platform, and can be extended 
dynamically. Java is a simple, object-oriented, network- 
savvy, interpreted, robust, secure, architecture neutral, 
portable, multithreaded, dynamic language. 

Java is a strongly typed programming language. A Java 
program is created by compiling source code written in Java 
Language's well defined format into a compact, 
architecture -neutral object code known as Java bytecode. 
Compilation normally consists of translating Java source 
code into a machine independent Java bytecode representa- 
tion. Java bytecodes are translated (interpreted) on the fly 
into native machine code for the particular CPU the appli- 
cation is running on. Bytecodes arc executed at runtime by 
an interpreter residing on the client computer. Runtime 
activities may include loading and linking the classes needed 
to execute a program, machine code generation and dynamic 
optimization of the program, and actual program execution. 

A program written in the Java Language compiles to a 
bytecode file that can run wherever a Java Platform is 
present. This portability is possible because at the core of a 
Java Platform is a Java Virtual Machine. Java bytecodes are 
designed to operate on a Java Virtual Machine (VM). 'Ilie 
Java Virtual Machine Ls an abstract computing machine that 
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has its own instruction set and uses various memory areas. 
A Java VM is not an actual hardware platform, but rather a 
low level software emulator that can be implemented on 
many different processor architectures and under many 

5 different operating systems. A Java VM reads and interprets 
each bytecode so that the instructions may be executed by 
the native microprocessor. Hence compiled Java bytecodes 
are capable of functioning on any platform that has a Java 
Virtual Machine implementation available. 

^0 However, bytecode interpretation detracts from program 
performance since the microprocessor has to spend part of 
its processing time interpreting bytecodes, Java "Just In 
Time" QVV) compilers were introduced to improve the 
performance of Java Virtual Machines. A Java JIT compiler 

IS translates Java bytecodes into the processor's native 
machine code during runtime. The processor then executes 
the compiled native code like any other native program. 
Such compiled Java programs execute much faster than Java 
programs that are executed using a Java interpreter 

Although a Just In Time compiled Java program executes 
faster than an interpreted Java program, the performance of 
such Just In Time compiled Java programs can be further 
improved. In order to harness performance improvements 
from Java code via JIT compilation, a program's Java 
bytecodes have to be JIT complied. Since Just In Time 
compilations are performed during program runtime, the 
compile time adds to the time constraint during execution 
time. Furthermore, since the native machine code outputted 
by a JIT compiler is not saved, the program's Java bytecodes 
have to be JIT compiled every time the program is loaded 
and run. JIT compilers also do not produce efiBcient code 
since they must quickly produce the code and thus the code 
is not optimized. 

35 SUMMARY OF THE INVENTION 

The present invention introduces a method for optimizing 
Java performance using precompiled code. The method of 
the present invention first monitors the performance of 

40 program code during program execution. Then a list of 
program functions for possible native code compilation is 
created. A plurality of program functions from said list of 
program functions is selected, l^e selected program func- 
tions are precompiled into native program functions. 

45 Other objects, features, and advantages of the present 
invention will be apparent from the accompanying drawings 
and from the detailed description that follows. 

BRIEF DESCRIPTION OF THE DRAWINGS 

50 The present invention is illustrated by way of example 
and not limitations in the figures of the accompanying 
drawings in which like references indicate similar elements, 
and in which: 

FIG. 1 is a block diagram illustrating a computer system 
which may utilize the present invention. 

FIG. 2 is a block diagram illustrating the Java Platform 
across operating systems. 

FIG. 3fl illustrates a flow diagram that lists the steps of 
gQ downloading and running a Java program in a Java Virtual 
Machine with an interpreter; 

FIG. 3b illustrates a flow diagram that lists the steps of 
downloading, compiling, and running a Java program in a 
Java Virtual Machine that compiles the code before execu- 
65 ^ion; 

FIG. 4 illustrates a block diagram of a Java Virtual 
Machine on a client computer system; 
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FIG. 5 is a flow chart illustrating the steps of one method 
for optimizing computer program code; 

FIG. 6 is a block diagram illustrating the runtime and 
compile-time environments of a Java Language develop- 
ment environment; 5 

FIG. 7 is a flow chart illustrating the steps of profiling and 
optimizing computer program code in one embodiment of 
the present invention; 

FIG. 8 is a block diagram illustrating one embodiment of 
the present invention in a Java Language development 
environment; 

FIG. 9 is a block diagram illustrating one embodiment of 
the present invention in a Java visual tuning environment; 

FIG. 10 is a block diagram illustrating one embodiment of 35 
the present invention in a native Java compilation model; 

FIG. Ha illustrates the contents of an entry in a list file of 
candidates for native compiling in one embodiment of the 
present invention; 

FIG. lib illustrates an example of a list file after static 
analysis in the compiler in one embodiment of the present 
invention; and 

FIG. 11c illustrates an example of a list file after recom- 
mendations by a native Java compiler of methods for native 
compiling in one embodiment of the present invention. 

DETAILED DESCRIPTION OF THE 
INVENTION 

A method for optimizing Java performance using precom- 
piled code is disclosed. In the following description, for 
purposes of explanation, specific nomenclature is set forth to 
provide a thorough understanding of the present invention. 
However, it will be apparent to one skilled in the art that 
these specific details arc not required in order to practice the 
present invention. For example, the present invention has 
been described with reference to Java object-oriented pro- 
gramming language. Although the foUowing embodiments 
are described with reference to the Java programming lan- 
guage and Java "Jusl-In-Time" (JIT) compilers, other 
embodiments are applicable to other types of programming 
languages that use compilers. The same techniques and 
teachings of the present invention can easily be applied to 
other types of compiled object code. 

A Java compiler converts Java source code into a verifi- 45 
ably secure and compact architecture-neutral intermediate 
format called Java bytecodes. A Java Virtual Machine (Java 
VM) later interprets the bytecode instructions at runtime. 

In order to improve runtime performance, a JIT compiler 
may convert bytecodes into native code at runtime. Even 50 
though a JIT compiler improves performance, Just-In-Time 
code generation has a time constraint — code compilation 
time is part of the run time. JIT compiled code runs faster, 
but only after being JIT compiled. Since JIT compiled code 
is not stored after program execution, the bytecodes need to 55 
be JIT compiled every time the program is loaded and run. 
While the traditional methodology of performance measure- 
ment used to ignore compilation time, measurements of JIT 
compiled program execution time must include JIT compi- 
lation time. As such, compilation speed becomes much more 60 
important in a Java JIT compiler than in a traditional 
compiler. As a result, it is extremely important for the code 
optimizations to be effective. Therefore, a method of 
improving Java perfonmance using precompiled code would 
be desirable. 65 

llie present invention introduces a method of improving 
Java performance by precompiling Java bytecodes into 



,506 Bl 

4 

native machine code. Precompiled code may improve pro- 
gram performance because the Java bytecodes do not have 
to be translated or compiled every time the program is 
loaded and executed. Hence, precompiled code may also 
afford some aggressive optimization techniques which con- 
sume more compile time. The precompiled native code may 
be stored in dynamic linked library (DLL) for later program 
execution. 

In one embodiment of the present invention, a high level 
performance analysis tool monitors the performance of a 
Java program or Java applet. An analysis tool may track the 
Java program methods entered and exited in memory, estab- 
lish a relationship between parent and child methods called, 
record every called program method, and time spend in each 
method. In another embodiment, an analysis tool may keep 
track of the Java methods being loaded into memory along 
with active software executing on the system. A tuning tool 
may determine the most active classes and methods in a Java 
application and list possible candidates for native compila- 
tion. Depending on the calling sequence of Java program 
methods and their execution time, users may select any 
arbitrary number of highlighted methods for static compi- 
lation. Static analysis by a Java compiler may also be a 
factor in the selection process. The Java compiler may use 
heuristics in static analysis — native interface overhead ver- 
sus optimization gain. 

In one embodiment of the present invention, a compiler 
translates Java bytecodes into native machine object code 
for program methods that are selected to be native compiled. 
The native compiled object code may be built into a DLL. 
Program methods that are native compiled will have their 
attributes in the class file changed. Additional mechanisms 
may facilitate the native code compilation by reverting the 
native bit back to Java method, reporting the attribute state, 
and adding Java code to load the DLL. After performance 
tuning, the precompiled Java program methods could run 
concurrently with the rest of the Java program *s bytecodes 
on a Java Virtual Machine. 

A Computer System Application 
Referring now to FIG. 1, there is a block diagram illus- 
trating a computer system 100 which may utilize the present 
invention. The system 100 includes a central processor 150 
which carries out the various instructions provided to the 
computer system 100 for its operations. The central proces- 
sor 150 comprises of an execution 152, and instruction unit 
154, cache memory 156, and general registers 158. The 
central processor 150 is coupled to a bus 140 adapted to 
carry information to various components of the system 100. 
Coupled to the bus 140 is main memory 110, which is 
typically constructed of dynamic random access memory 
arranged in a manner well known to those skilled in the prior 
art, to store information during a period in which power is 
provided to the system 100. Also coupled to the bus 140 is 
read-only memory 130, which may include various memory 
devices well known to those skilled in the art, each of which 
is adapted to retain a particular memory condition in the 
absence of power to the system 100. The read-only memory 
130 typically stores various basic functions used by the 
processor 150 such as basic input/output processes and 
start-up processes typically referred to as BIOS processes. 
Long tenn memory 120 is also coupled to the bus 140. The 
constmction and operation of long term memory 120, typi- 
cally electro-mechanical hard disk drives, is well known to 
those skilled in the art. 

The Java Platform 
FIG. 2 is a block diagram illustrating the Java platfonn 
across some difi'erent operating systems. The Java Platform 
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is a software platform for delivering and running highly The Java Native Interface as described in the above embodi- 

interaclive, dynamic, and secure applets and applications on ment is only one example of a native method interface. In 

networked computer systems. The Java Platform sits on top other embodimeDts of the present invention, other native 

of many other platforms, including Microsoft Windows, method interfaces may be utilized, such as Microsoft's Raw 

Macintosh, OS/2, UNIX, and NetWare, and compiles to 5 Native Interface (RNl), Netscape's Java Runtime Interface 

bytecodes, which are not specific to any physical machine, (JRI), and many others. 

but are machine instructions for a Java virtual machine. A The Porting Interface 214 lies between the Java VM 212 
program written in the Java Language compiles to a byte- and the operating system (OS) 224, 232, 242, 250 or browser 
code file that can run wherever the Java Platform is present, 222. In this embodiment, the Porting Interface 214 has a 
on any underlying operating system. The Java Platform has ]0 platform independent part (Java Base Platform) and a plat- 
two basic parts: the Java Virtual Machine and the Java form dependent part (adapters 220, 230, 240), The OS 224, 
Application Programming Interface. 232, 242 and JavaOS 250 provide the window, filing, and 
Java Virtual Machine (Java VM) 212 is a "soft" network functionality. In FIG. 2, four difTerent types of 
computer that can be implemented in software or hardware. machines are illustrated. The first machine (Java on a 
It is an abstract machine designed to be implemented on top 35 Browser) comprises of adapter 220, browser 222, operating 
of existing computer processors. The Java Platform's Port- system 224, and hardware 226. A second machine (Java on 
ing Interface 214 and Adapters 220, 230, 240 enable the Java a desktop OS) comprises of adapter 230, operating system 
VM 212 to be easily ported to new operating systems 224, 232, and hardware 234. A similar machine (Java on a smaller 
232, 242, 250 without being completely rewritten. OS) includes adapter 240, operating system 242, and hard- 

The Java Application Programming Interface (Java API) 20 ware 244. Yet another machine (Java on JavaOS) may 

204, 208 forms a standard interface to applets and comprise of JavaOS 250 and hardware 252. These and other 

applications, regardless of the underlying operating system. different machines can all be connected by a network 260. 

The Java API specifies a set of essential interfaces in a n • i c i 

number of areas that software developers may use to build Runnmg a Java Class File 

Java-powered applications. The Java API may be further 25 An example of running a Java program in a networked 

divided into the Java Base API 204 and the Java Standard computer environment is provided with reference to FIG. 3fl 

Extension API 208. The Java Base API 204 provides the and FIG. 4. FIG. 3a illustrates the steps in downloading and 

basic language, utility, input/output, network, graphical user running a Java program in a Java VM with an interpreter, 

interface, and applet services. The Java Standard Extension piG. 4 illustrates a block diagram of the elements in a chent 

API 208 extends the capabilities of Java beyond the Java computer system 400 equipped to interpret and compile Java 

Base API 204. Other nonstandard extension APIs can be ^lass files. The client computer system 400 includes com- 

provided by the applet, appUcation, or underlying operating ^^^^^ hardware 410 controlled by an operating system 420. 

system. yj^^ computer hardware further comprises of computer 

The Java Base Platform in FIG. 2 includes the following memory 412 and machine registers 414. The system 400 

blocks or components: Java Base API 204, Java Base ^Iso includes a Java VM implementation 430 for running 

Classes 206 Java VM 212 Porting Interface 214, and j^^^ ^^^^ embodiment, the Java VM 430 

Adapters 220, 230 240. In this embodiment the Java API ^^^^ ^„ ^^^^^ 

includes both the Java Base API 204 and Java Standard • r ,u j 1 - * vim j *u 
Extension API 208. TTie classes (Java Base Classes 206 and ^^^^f ^'^'^}^' ""^i n 1'^ ^^V.^ 
Java Standard Extension Classes 210) are the implementa- ^°"^P^^^^ 4ia Furthermore, the Java VM 430 may 
tion of its respective API. The Java VM 212 is at the core of ^0 use a Java Interpreter 432 to interpret Java classes 460 or a 
the Java Base Platform. A Java Native Interface (JNI) may •'^^^ -^"^ compiler 434 to generate compiled native code, 
exist with the Java VM 212. The Java Native Interface is a a networked environment, a user would first access a 
standard programming interface for writing Java native computer server through the network and download the 
methods and embedding the Java VM into native applica- desired Java class file 460 into a client computer system 400 
tions. While users write applications entirely in Java, there 45 as in step 310 of FIG. 3a . After the class file 460 has been 
are situations where Java alone does not meet the needs of downloaded, it is passed into the Java VM 430, which then 
an application. Programmers use the JNI to write Java native verifies the downloaded class file at step 320. Step 320 of 
methods to handle those situations when an application verifying the class file is to ensure that the program will not 
cannot be written entirely in Java. The following examples cause security violations nor will it cause harm to the 
illustrate when you need to use Java native methods: jq computer system resources. After the Java class file has been 
The standard Java class library does not support the verified, the interpreter 432 begins interpreting the Java 
platform-dependent features needed by the application. bytecodes of the class file 460. The Java program bytecodes 
A library may already be written in another language and are interpreted in step 330 so that the Java application can be 
a programmer wishes to make it accessible to Java code executed. Since the bytecodes being interpreted are gener- 
through the JNI. 55 ally not native to the processor, the interpretation process 
A programmer may want to implement a small portion of ^^^^ ^low Hence, Java "Just-In-Time" compQation 
time-critical code in a lower-level language such as mtroduced to improve the performance of Java pro- 
assembly. S'^^'^s- 
By programming through the JNI, developers can use native ^nd FIG. 4 are used to describe how a Java 
methods to: ^0 program can be compiled and then executed. FIG. 3b 
Create, inspect, and update Java objects (including arrays illustrates a flow diagram that lists the steps of downloading, 
and strinss) compilmg, and runmng a Java program m a Java VM that 
^ , . . compiles the code in native machine code before execution. 
Call Java methods. it- . t 1 ci a^a 

First, a user accesses a Java class file 460 on a computer 

Catch and throw exceptions. ^5 network and downloads the class file 460 to a local client 

Load classes and obtain class informalioo. computer system 400 as in step 350. Then at step 360, the 

Perform runtime type checking. Java VM 430 verifies the downloaded class file 460. After 
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the Java program has been verified, a Java JIT compiler 434 a Java compiler 610 to compile it to bytecodes (.class files) 
compiles the Java class file and generates compiled Java 615. These bytecodes 615 are instructions for a Java VM 
code 440 in the form of native processor code at step 370. 640. In order to create an applet, a developer may store these 
The compiled Java code 440 is directly executed on the bytecode files 615 on a HTTP server and add an <applet 
computer hardware 410 at step 380. Java programs which 5 code«filename> tag to a Web page, which names the entry- 
have been compiled and translated into native code execute point bytecode file. When an end user visits that page, the 
faster than Java programs that are executed using a Java <applet> tag causes the bytecode files to be transported over 
interpreter because the compiled code is native to the a network 620 from the server to the end user's browser in 
computer processor in the client system 400. In order to the Java Platform. At the Java Platform, the bytecodes are 
maintain the state of the Java VM 430 and make system lo loaded 625 into memory and then verified for security before 
calls, the compiled Java code 440 may make calls 450 into entry into the Java VM 640, Once the bytecodes are in the 
the Java VM 430. Java VM 640, the bytecodes are interpreted by a Java 
Although the above example describes the distribution of interpreter 642 or turned into native machine code by the JIT 
a Java class file via a network, Java programs may be compiler 644. The Java interpreter 642 and JIT compiler 
distributedby way of other computer readable mediums. For 15 operate in the context of the runtime system 646 (threads, 
instance, a computer program may be distributed through a memory, and other system resources). Any classes from the 
computer readable medium such as a floppy disk, a CD -^ava Class Libraries 630 are dynamically loaded as needed 
ROM, a carrier wave, or even a transmission over the applet. 



internet. 



20 



Optimizing Using Precompiled Code 



Prior Method For Optimizing Code FIG. 7 is a flow chart illustrating the steps of profiling and 

^ . „ , , , optimizing computer program code in one embodiment of 

nC. 5 IS a flow chart lUustratmg the steps of one method ^^^^^^^ invention. A programmer would first write a 

for optimizmg computer program code. Software developers computer program in the Java programming language in step 

may often decide to optimize computer programs m attempt ^5 705. At step 710, the program would be compiled and 

to improve performance. One such code optimization tested/debugged. Then at step 715, the programmer may use 

method may entail the steps as shown m FIG. 5. As in step ^ ^^^^^g monitoring tool to monitor and perform static] 

505, a programmer may first write a program in a high level and dynamic-a^naipis-of'thT^Si^SSV^ 

language like C or C++. Then the program would be ja^pPogram meth-5drtharmay impraVe program per- 

compiled at step 510. If the program compiles, the program- 3^ formance if optimized is generated at step 720. If the 

mer may go on lo tesl/debug the prograni and analyze its p^grammer finds that the performance is satisfactory at step 

performance at step 515. Performance analysis may include 725, then development of the program is done. However, if 

dynamicaUy measuring each ftinction s or Java program j^e programmer decides to try to improve performance, then 

methods execution time. If program performance is at step 730, he may select some of the Java program methods 

satisfactory, then the code development process is com- 3^ on the candidate list from step 720 for optimization. At step 

pleted. However, if the performance of the computer pro- 735^ ^^j^^j^ j^^^ ^ ^^^^^^^ optimized and 

gram IS not satisfactory at step 520, the developer may select compiled into native processor code by a native Java com- 

certam sections of the program for optimization. ^^^^ alternatively, a user may decide to de-compile 

One popular way of optimizing code is to rewrite some earlier native compiled code back to bytecode format. The 

functions or procedures in a low level language or native 40 de-compile process may be used for instance when a user 

machine code as in step 525. A programmer would have to determines that the native compiled code does not present 

estimate if rewriting portions of the code in another Ian- the desired performance and the user wants to revert the 

guage could be helpful. If the programmer decides to rewrite native compiled code back to Java bytecode. A dynamic 

the slower functions or program methods, he may also have linked library (DLL) is created for the compiled native 

to add code to perform Java specific checks, resolve any 45 program methods at step 740. At this point, the development 

different language semantics, optimize the compiler to process may be complete. However, a programmer may 

eliminate native interface overhead, perform control flow repeat these steps to further refine and optimize the program, 

and data flow analysis to optimize Java specific checks, and The process of monitoring and compiling bytecode/de- 

to implement using a native interface. However, such a compiling native code may be repeated until the desired 

process may prove to be tedious and time consuming since 5Q performance is obtained. 

the programmer usually has to repeal the steps of compila- pjc. 8 is a block diagram iUustrating one embodiment of 
tion 510 and testing 515. This process may also prove to be the present invention in a Java Unguage development 
difficult to perform without a user interface for performance environment. The Java Language development environment 
tunmg programs. Furthermore, the programmer may not shown comprises of a compile-time and a runtime environ- 
even know if the optimizations were effective or not without 55 ment. A programmer writes Java source code 805 and 
more performance analysis. Hence a programmer may compiles the source code into Java bytecodes 815 with a 
repeat the process of rewriting code, compiling, and testing Java compfler 810. In order to create an applet, a developer 
several times before achieving the desired performance if at ^ay store these bytecode files 815 on a HTTP server and add 

an <applet code=filenarac> lag to a Web page, which names 

Java Developmenl Environment entry-point bytecode file. However, the programmer may 

^ decide to optimize or native compile certain Java program 

FIG. 6 shows the runtime and compile-time environments methods. The programmer would compile selected program 

of a Java Language development environment 600. A Java methods with the native Java compiler 860 to generate 

Language development environment 600 includes both native object code and Java bytecodes 870. When an end 

compile-time and runtime environments. The Java Platform 65 user visits that page, the <applet> tag causes the native 

is represented by the runtime environment. A developer object code and bytecode files to be transported over a 

writes Java Language source code (.java files) 605 and uses network 820 from the server to the end user's browser in the 
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Java Platform. lo another embodimeat, the native compiled 
code may be downloaded or transported into a client system 
by a browser via other mediums or methods. Furthermore, in 
other embodiments of the present invention may utilize 
some alternative file transfer protocol in downloading native 5 
compiled code so that a user could tune a Java program on 
a client system. At the Java Platform, the bytecodes are 
loaded 825 into memory and then verified for security before 
they enter the Java VM 840. Once the bytecodes are in the 
Java VM 840, they are interpreted by a Java interpreter 842 -jq 
or turned into native machine code by the JIT compiler 844. 
The Java interpreter 842 and JIT compiler operate in the 
context of the mntime system 846 (threads, memory, and 
other system resources). Any classes from the Java Class 
Libraries 830 are dynamically loaded as needed by the 35 
applet. 

FIG. 9 is a block diagram illustrating one embodiment of 
the present invention in a Java visual tuning environment. In 
one embodiment of the present invention, a high level 
monitoring tool 960 monitors the performance of a Java 20 
application 910 and presents a list of possible Java program 
methods for optimization. A tuning and monitoring tool 960 
may further comprise of a native Java compiler 920 and a 
performance analyzer 930. Based on the calling sequence of 
Java program methods and their execution time, plus static 2s 
analysis done by the Java compiler, users could select any 
arbitrary number of highlighted methods for static compi- 
lation. The Java compiler may also use heuristics in static 
analysis — native interface overhead versus optimization 
gain. 30 

For this example situation, a user has selected the Java 
program methods in Class B 914 of a Java application 910 
for native compilation. The Java program methods that are 
selected for native compilation are first translated firom Java 
bytecodes into native processor object code by a native Java 35 
compiler 920. The native object code could be built into a 
dynamic linked library (.DLL). In this case, B.dll 955 has 
been created fi-om the native processor object code. In the 
Java application after native compilation 950, Class B 954 
still exists because Class B 954 contains the right native 40 
attribute for the Java VM 940 to resolve calls. For the 
program methods that have been native compiled, the native 
Java compiler would change their attributes from the origi- 
nal class file, Class B 914. Suppose Class B contains a 
method X. When another program method calls X, the Java 45 
VM prepares the call diGferently when X is a Java program 
method versus a native compiled method. The Java VM uses 
the attribute associated with X to determine if X is a native 
compiled or a Java method. After the native compilation, 
class B is still needed even though the bytecode is already 50 
translated to native compiled code because of the attribute 
information. In one embodiment of the present invention, 
there may be mechanisms which facilitate the native com- 
pilation. For example, mechanisms to revert the native bit 
back to Java method, reporting the attribute state, and adding 55 
Java code to load the DLL. The native Java compiler may 
also optimize bytecodes statically for Java specific features 
and code sequences dynamically while calling a native 
method. After the original Java application 910 has been 
tuned, the precompiled Java program methods in the B.dll 60 
955 could run concurrently with the rest of the Java byte- 
codes of the Java application 950 on a Java VM 940. 

FIG. 10 is a block diagram illustrating one embodiment of 
the present invention in a native Java compilation model. In 
this example, a Java application is composed of two Java 65 
source code files — Ajava 1005 and B.java 1015. These two 
source code files are compiled with a Java compiler 1030 to 
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generate A.class 1010 and B. class 1020, respectively. The 
Java application comprising of these two class files 1010, 
1020 may then be executed on a Java VM 1080. However, 
a programmer may decide to optimize the Java program 
method which has bytecode Getfield of *a' fi-om class B in 
A.class 1010. Hence what was originally Ajava 1005 is 
precompiled with the native compiler 1040 into native code 
A.obj and then Lib.dli 1060. Therefore, the Java application 
now comprises of Lib.dli 1060, A.class 1010, and B.class 
1020 and may be executed on a Java VM 1080. When the 
method in A.class 1010 is native compiled, it needs to use 
the Java native interface 1070 to access the field b in class 
B 1020. 

FIGS. 11a, lib, and 11c are used to illustrate some 
outputs from a tuning and monitoring tool using the present 
invention in one embodiment, FIG. 11a illustrates the con- 
tents of an entry in a list file of candidates for native 
compiling in one embodiment of the present invention. The 
list file contains a list of Java program methods that are 
candidates for native compiling after static analysis is per- 
formed in the compiler. In the present embodiment, each line 
contains information about the candidate in three fields 
1110, 1112, 1114. The first field 1110 contains the name of 
the class file containing the Java program method. The 
second field 1112 contains the name of the actual program 
method. An the third field 1114 contains a weight value. The 
weight is a number indicating the result of the static analysis 
that the compiler performed 00 the method. The higher the 
number, the better the performance gain the native compi- 
lation should bring. 

In the present example, the tuning and monitoring tool 
would pass the list file in FIG. 116 to the native Java 
compiler. FIG. 116 illustrates an example of a list file before 
static analysis in the compiler in one embodiment of the 
present invention. The program methods, "handleEvcnt" 
method on line 1120 and "Point" method on line 1122, 
indicated in this list file are program methods that took a 
long time to run. 

After the static analysis, the tuning and monitoring tool 
would see the list file in FIG. 11c. FIG. lie illustrates an 
example of a list file after recommendations by a native Java 
compiler of methods for native compiling in one embodi- 
ment of the present invention. The "handleEvent" method on 
line 1130 have been given a weight of 0 and the "Point*' 
method on line 1132 has a weight of 100. In this example, 
the native compiler only recommends that the "Point" 
method on line 1132 be native compiled. 

In the foregoing specification, the invention has been 
described with reference to specific exemplary embodiments 
thereof. It will, however, be evident that various modifica- 
tions and changes may be made thereto without departing 
firom the broader spirit and scope of the invention as set forth 
in the appended claims, llie specification and drawings are 
accordingly to be regarded as illustrative than a restrictive 
sense. 

What is claimed is: 

1. A method of optimizing program code performance 
comprising: 

monitoring performance of program code during program 
execution; 

creating a list of program functions for possible native 
code compilation; 

selecting a subset of program functions based on execu- 
tion times of said program functions fi'om said list for 
optimization and native code compilation; and 

precompiling said selected program functions into native 
program hinctions. 
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2. The method of claim 1 wherein said program fuDCtions creating a list of program functions for possible native 
comprise of Java class methods. code compilation; 

3. The method of claim 1 wherein said monitoring further selecting a subset of program functions from said list 
comprises of: based on execution time of each program function for 

dynamically analyzing performance of said program 5 optimization and native code compilation; and 

code; and precompiling said selected program functions into native 

statically analyzing performance of said program code. program functions. 

4. The method of claim 1 wherein said monitoring com- l^- Th^ computer readable medium having embodied 
prises of dynamically analyzing performance of said pro- thereon a computer program of claim 18 wherein said 
gram code. program functions comprise of Java class methods. 

5. The method of claim 1 wherein said monitoring com- 20. The computer readable medium having embodied 
prises of statically analyzing performance of said program thereon a computer program of claim 18 wherein said 
code. monitoring further comprises of: 

6. The method of claim 1 wherein said program code dynamically analyzing performance of said program 
comprises of Java bytecodes. code; and 

7. The method of claim 1 further comprising storing said statically analyzing performance of said program code, 
native program functions to be executed at a later time 21. The computer program being executable by a machine 
without having to recompile said program functions. of claim 18 to further perform calling said native program 

8. The method of claim 1 further comprising of calling functions instead of said program functions during later 
said native program functions instead of said program program executions. 

functions during later program executions. 22. The computer program of claim 18 wherein said 

9. The method of claim 1 wherein said subset includes program code comprises of Java bytecodes. 

entire set of program functions on said list. 23. The computer readable medium of claim 18 wherein 

10. The method of claim 1 wherein said subset includes said subset includes entire set of programs functions on said 
less than entire set of program functions on said list. list. 

11. The method of claim 1 wherein said selecting com- 24. The computer readable medium of claim 18 wherein 
prises user interaction in evaluating said list. said subset includes less than entire set of program functions 

12. A method of optimizing program performance com- on said list. 

prising: 25. The method of claim 18 wherein said selecting 

monitoring performance of a computer program during comprising a user interactively reviewing and selecting 

program execution; program functions from said list, 

creating a list of program class methods for possible 26. A digital processing system having a processor oper- 

native code compilation; ^^^^ '° P«ff°™ ^ '^''^°<^ comprismg: 

, u . r 1 .u J f J I- . monitoringperformanceof program code during program 

selecting a subset of program class methods from said list 35 ^ ^ &r & 

execution* 

based on execution times of said program class meth- . ,.' - „ ■ ^ 

ods for optimization and native code compilation; ^'^^'If 8 " P'"^^^"' P°^*^^ 

code compilation; 

precompiling said selected program class methods into , . u * c c c -j i* . 

, <u 1 3 selectmg a subset of program functions from said list 

native class methods; and .5* f- r ■ j 

40 based on execution times for optimization and native 

storing said native class methods, said native class meth- ^ode compilation* and 

ods to be executed at a later time without having to be precompiling said selected program fimctions into native 

recompiled^ program functions. 

13. The method of clami 12 wherein said momtonng 27. A digital processing system of claim 26 wherein said 
rurther comprises ot. program functions comprise of Java class methods. 

dynamically analyzing performance of said computer 28. A digital processing system of claim 26 wherein said 

program; and monitoring further comprises: 

statically analyzing performance of said computer pro- dynamically analyzing performance of said program 

gram. code; and 

14. The method of claim 12 wherein said computer 50 staticlly analyzing performance of said program code, 
program comprises of Java bytecodes. 29. The digital processing system of claim 26 to further 

15. 'l^e method of claim 12 further comprising of calling perform calling said native program functions instead of said 
said native class methods instead of said program class program functions during later program executions, 
methods during later program executions. 30. The digital processing system of claim 26 wherein 

16. The method of claim 12 wherein said subset included 55 said program code comprises of Java bytecodes. 

entire set of program class methods on said list. 31, The digital processing system of claim 26 wherein 

17. The method of claim 12 wherein said subset includes said subset includes entire set of program functions on said 
less than entire set of program methods on said list. 

18. A computer readable medium having embodied 32. The digital processing system of claim 26 wherein 
thereon a computer program, the computer program being said subset includes less than entire set of program functions 
executable by a machine to perform a method comprising: qq ^^id Ust. 

monitoring performance of program code during program 

execution; ♦ * * ♦ * 
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